fe-blog

一、开发体验：让用户少走弯路

一个框架好不好，很大程度上取决于它是否让开发者用得顺手。好的开发体验能帮助开发者快速定位问题，减少开发过程中的挫败感。以 Vue.js 3 为例，当你尝试将应用挂载到一个不存在的 DOM 节点上时，框架会抛出清晰的警告信息：

createApp(App).mount('#not-exist')

这会触发类似“挂载失败，选择器未找到对应 DOM 元素”的警告。这样的提示不仅指出了问题，还说明了原因，让开发者能迅速找到解决办法。相比之下，如果框架只抛出类似 Uncaught TypeError: Cannot read property 'xxx' of null 的原生错误，用户可能需要花更多时间排查。

如何提升开发体验？

提供友好的警告信息：通过 warn 函数输出清晰的提示，比如 Vue.js 3 中的错误栈信息。这需要框架在设计时主动捕获潜在问题，并在适当位置调用 console.warn。
优化控制台输出：例如，Vue.js 3 通过自定义 formatter（如 initCustomFormatter 函数）优化了 ref 对象的控制台输出。在浏览器 DevTools 开启“Enable custom formatters”后，console.log(ref(0)) 的输出从晦涩的对象结构变成直观的 Ref<0>，极大提升了调试效率。

这些设计看似简单，但背后需要框架开发者深入理解用户的使用场景，预判可能出错的地方，并提供直观的反馈。

二、控制代码体积：开发与生产的平衡

框架的功能越完善，往往意味着代码量越大，尤其是那些为提升开发体验而添加的警告信息。然而，生产环境中，代码体积直接影响加载速度和用户体验。如何在提供丰富功能的同时保持代码精简？答案在于利用构建工具的优化机制。

DEV 常量与条件编译

Vue.js 3 通过 __DEV__ 常量区分开发和生产环境。例如：

if (__DEV__ && !res) {
  warn(`Failed to mount app: mount target selector "${container}" returned null.`)
}

在开发环境中，__DEV__ 被构建工具（如 Rollup.js）替换为 true，警告代码生效；而在生产环境中，__DEV__ 被替换为 false，条件分支成为“死代码”（dead code），会被构建工具移除。这种条件编译的方式确保了生产环境的代码体积不会因为开发体验的优化而增加。

构建产物的多样化

为了满足不同场景的需求，框架需要输出多种构建产物。例如，Vue.js 3 提供以下几种格式：

IIFE（立即调用函数表达式）：如 vue.global.js，适合通过 <script> 标签直接引入，适用于简单的浏览器端应用。
ESM（ES Module）：分为 vue.esm-browser.js（直接用于 <script type="module">）和 vue.esm-bundler.js（供 Webpack/Rollup 等打包工具使用）。两者的区别在于，-bundler 版本将 __DEV__ 替换为 process.env.NODE_ENV !== 'production'，让用户通过打包工具决定环境。
CommonJS：如 vue.cjs.js，用于 Node.js 环境下的服务端渲染。

这种多样化的产物设计让框架能够适配不同的使用场景，同时通过条件编译保持体积可控。

三、Tree-Shaking：让用户只打包需要的代码

框架往往内置了许多功能，但用户可能只需要其中一部分。如何避免将未使用的代码打包到最终产物中？答案是 Tree-Shaking，一种依赖 ESM 静态结构的优化机制，可以移除未被引用的代码。

Tree-Shaking 的工作原理

以一个简单例子说明：

// utils.js
export function foo(obj) {
  obj && obj.foo
}
export function bar(obj) {
  obj && obj.bar
}

// input.js
import { foo } from './utils.js'
foo()

使用 Rollup.js 构建后，输出的 bundle.js 只包含 foo 函数，bar 函数被作为死代码移除。这是因为 Rollup.js 能静态分析 ESM 的引用关系，判断哪些代码未被使用。

但有时候，静态分析会因为“潜在副作用”而保留看似无用的代码。例如，foo 函数可能操作了 Proxy 对象，触发副作用。为了明确告诉构建工具某段代码无副作用，可以使用 /*#__PURE__*/ 注释：

/*#__PURE__*/ foo()

这会提示 Rollup.js 安全移除无副作用的代码。Vue.js 3 源码中大量使用了这种注释，确保未使用的功能（如 <Transition> 组件）不会被打包。

特性开关：灵活控制功能

为了进一步提升灵活性，框架可以通过“特性开关”让用户选择性启用功能。例如，Vue.js 3 支持选项 API 和组合式 API，用户可以通过 __VUE_OPTIONS_API__ 开关决定是否包含选项 API 的代码：

if (__FEATURE_OPTIONS_API__) {
  // 选项 API 相关代码
}

用户可以通过 Webpack 的 DefinePlugin 设置 __VUE_OPTIONS_API__ 为 false，从而移除相关代码。这种机制不仅减小了打包体积，还为框架升级提供了兼容性支持，比如保留旧 API 供老用户使用。

四、错误处理：让框架更健壮

一个优秀的框架不仅要帮助用户快速开发，还要保证应用的健壮性。错误处理是关键一环，直接影响用户的心智负担和应用稳定性。

统一的错误处理接口

以一个工具模块为例：

export default {
  foo(fn) {
    fn && fn()
  }
}

如果用户传入的回调函数抛出异常，框架需要提供统一的错误处理机制，而不是让用户在每个调用处手动添加 try...catch。Vue.js 3 采用了一种优雅的解决方案：

let handleError = null
export default {
  foo(fn) {
    callWithErrorHandling(fn)
  },
  registerErrorHandler(fn) {
    handleError = fn
  }
}
function callWithErrorHandling(fn) {
  try {
    fn && fn()
  } catch (e) {
    handleError(e)
  }
}

用户通过 registerErrorHandler 注册全局错误处理函数，所有异常都会被统一捕获并传递给用户定义的处理器。这种设计让用户代码更简洁，同时支持灵活的错误处理策略，比如忽略错误或上报到监控系统。

五、TypeScript 支持：不仅仅是类型声明

TypeScript（TS）越来越受欢迎，框架对 TS 的支持程度也成为评价其优劣的重要标准。但很多人误以为用 TS 编写框架就等于提供了良好的类型支持，这其实是两回事。

类型推导的挑战

以一个简单函数为例：

function foo(val: any) {
  return val
}

调用 foo('str') 时，返回值类型被推导为 any，这对开发者并不友好。通过使用泛型改进：

function foo<T>(val: T): T {
  return val
}

现在，foo('str') 的返回值类型被正确推导为字符串字面量 'str'。Vue.js 3 的源码中，类型推导的实现往往比功能代码本身更复杂。例如，runtime-core/src/apiDefineComponent.ts 文件中，实际运行时代码只有几行，但为了类型支持，代码量接近 200 行。

TSX 支持

除了类型推导，框架还需要考虑对 TSX（TypeScript 的 JSX 语法）的支持，确保开发者在使用 TSX 编写组件时能获得良好的类型提示和错误检查。

#一、开发体验：让用户少走弯路

#如何提升开发体验？

#二、控制代码体积：开发与生产的平衡

#DEV 常量与条件编译

#构建产物的多样化

#三、Tree-Shaking：让用户只打包需要的代码

#Tree-Shaking 的工作原理

#特性开关：灵活控制功能

#四、错误处理：让框架更健壮

#统一的错误处理接口

#五、TypeScript 支持：不仅仅是类型声明

#类型推导的挑战

#TSX 支持